<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
<meta name="GENERATOR" content="TtH 3.67">
 <style type="text/css"> div.p { margin-top: 7pt;}</style>
 <style type="text/css"><!--
 td div.comp { margin-top: -0.6ex; margin-bottom: -1ex;}
 td div.comb { margin-top: -0.6ex; margin-bottom: -.6ex;}
 td div.hrcomp { line-height: 0.9; margin-top: -0.8ex; margin-bottom: -1ex;}
 td div.norm {line-height:normal;}
 span.roman {font-family: serif; font-style: normal; font-weight: normal;} 
 span.overacc2 {position: relative;  left: .8em; top: -1.2ex;}
 span.overacc1 {position: relative;  left: .6em; top: -1.2ex;} --></style>
 

      
<title> Visual Workflow Editor</title>
</head>

<body>
 <h1><a name="tth_chAp1"></a>Requirements and Software Architecture </h1>
<br/>

<h2><a name="tth_sEc1"></a>Functional requirements </h2>

<p>
Functional requirements describe <i>what</i> the system should do,
without focusing on <i>how</i> it will be realized. Because of the
Visual Workflow Editor being a GUI, the functional requirements are
actually defined by the users requirements. The user should be able
of:
</p>

<ul>
<li> 
Create a Diagram representing a workflow
</li>

<li> 
Set the diagram properties, in particular details about the
OGSA-DAI service
</li>

<li> 
Add an Activity to the workflow using a palette and a panel to place
the elements.
</li>

<li> 
Set the activity properties, selecting the possible values from list
retrieved from the OGSA-DAI service.
</li>

<li> 
Add inputs and outputs to an activity
</li>

<li> 
Link two activity together, using a graphical tool that allows to
select the source and destination of the connection
</li>

<li> 
Save/Load a workflow diagram
</li>

<li> 
Validate the correctness of a workflow
</li>

<li> 
Deploy a workflow to an OGSA-DAI service
</li>

<li> 
Receive the result of execution from the OGSA-DAI service
</li>
</ul>



<a name="tth_fIg1"></a>
<center>
<img src="gfx/highlevel_sequence.png" alt="gfx/highlevel_sequence.png" /><br/>
Figure 1:High level sequence diagram
<a name="fig:highlevel_sequence"></a>
</center>

<p>
<a href="#fig:highlevel_sequence">Figure&nbsp;1</a> shows a sequence
diagram, with some high level actions driven by the user.
</p>

<h2><a name="tth_sEc2"></a>Non-functional requirements</h2>

<p>
Non-functional requirements cover general design guidelines and system
constraints that can be identified during the requirements definition
phase. Those are the non-functional requirements of the Visual
Workflow Editor: 
</p>

<ul>
<li> 
it should be user friendly, and give the possibility to build a
workflow using graphical elements such a palette of tools and a panel
to compose them. Well know mechanisms, like drag-and-drop, palette
tool and copy paste, should be available to the user.
</li>

<li> 
it must be operating system independent, and portable without any
additional modification.
</li>

<li> 
it must be easily extendible, in terms of design using an object
oriented paradigm, and in terms of third part extension by mean of
plugins.
</li>

<li> 

it must be modular, using a Model View Control patter to interconnect
each module, and giving the possibility to be reused and integrated in
other products 
</li>

<li> 
the user generated diagram must be transformed in a valid document
based workflow that can be submitted to OGSA-DAI service
</li>
</ul>


<h2><a name="tth_sEc3"></a>Software Architecture</h2>

<p>
The requirements that have been identified for the project, describe a
problem that involves different elements of the system, from the UI
interacting with the user, to the business logic that communicates
with the OGSA-DAI service. To achieve a better understanding of the
problem, and organise in an effective way the implementation of the
project, is worth to define the <i>Software Architecture</i> of the
project. In ] the architecture of a software is defined as:
</p>

<blockquote>
	The software architecture of a program or computing system is
the structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and the
relationships among them.  
</blockquote>

<p>
According to the definition an architecture defines elements and gives
information on the way they relate to each other. Thus, an
architecture is an abstraction that gives an high level view of the
problem, skipping details that do not effect how they use or are used
by or interact with other elements.
</p>

<p>
The project has been break down in four implementation units (called
module or package), with specific behaviour and responsibilities:
</p>

<ul>
<li> Resource and Activity Discovery (RAD)</li>

<li> Visual Workflow Representation (VWR)</li>

<li> Diagram Serialisation and Validation (DSV)</li>

<li> Workflow Execution (WE)</li>

</ul>


<h3><a name="tth_sEc3.1"></a>Resource and Activity Discovery</h3>

<p>
The central unit of an OGSA-DAI workflow are activities, that are
strictly coupled with OGSA-DAI resources. This module is in charge of
interacting with the OGSA-DAI service, fetching informations about the
resources and the activities that are deployed on it. In terms of the
functionalities offered to the other system modules, it can be
considered as belonging to the business logic layer; in terms of
technology it can be considered as a client that uses the CTK to
exchange messages with the OGSA-DAI service.
</p>

<h3><a name="tth_sEc3.2"></a>Visual Workflow Representation</h3>

<p>
This module is the central package of the project, and for its
importance the methodology and technology used to design it are
explained in detail in the <a href="chapter2.html">methodology
chapter</a>. From an abstract and high level point of view, the module
manages the graphical representation and composition of an OGSA-DAI
workflow. This element of the architecture is in charge of the UI, and
uses the functionalities exposed by others modules to obtain data from
the OGSA-DAI service, accomplish to load/save operation and execute
the workflow.
</p>

<h3><a name="tth_sEc3.3"></a>Diagram Serialisation and Validation</h3>

<p>
One of the non-user requirements, is that from the diagram must be
possible to produce a valid <i>XML</i> file, according to the
definition of OGSA-DAI workflow. The Diagram Serialisation is in
charge of transforming the diagram produced by the main module, in a
format that can be "executed" by OGSA-DAI engine. The Validation
feature is in charge of checking if the produced file, is a valid
OGSA-DAI workflow definition, checking it against a set of
constraints. This module might be considered as a subsection of the
Visual Workflow Representation, but at this stage it's important to
remark that the VWR module is dealing with "graphical" representation
of the workflow, while the DSV module deals with a low level
representation of the workflow.
</p>

<h3><a name="tth_sEc3.4"></a>Workflow Execution</h3>

<p>
This module is in charge of submitting a document description to the
OGSA-DAI service in order to execute the workflow it self. It has to
deal with all the features that are related to the execution, such as
execution status report and execution monitoring.
</p>


<h3><a name="tth_sEc3.5"></a>Module interaction</h3>

<p>
In the <a href="#fig:system_architecture">Figure&nbsp;2</a> is
represented the system architecture, and the interaction between each
module. Is important to underline that core module (VWR) access
OGSA-DAI only through RAD and WE modules. This solution adds a level
of abstraction, and makes the Visual Workflow Representation module
more general.
</p>


<a name="tth_fIg2"></a>     
<center>    
<img src="gfx/system_architecture.png" alt="gfx/system_architecture.png" />
<br/>
Figure 2:System architecture representation and interaction
<a name="fig:system_architecture">
</a>
</center>

</body>

</html>